I still believe OutputsSpec::All is a gross violation of store layer responsibilities. The store layer is not a package manager and it is up to the caller (libexpr and above, or alternate frontends) to assign meaning to individual outputs. (EDIT: including the possibility of all individual outputs, but handled by the frontend)

My "esse delendam" aside, this change is good JSON modeling.
Do I understand correctly that this JSON format is not in use by the public yet? (If it is, a release note should be added, as well as relevant version field bumps, if not already bumped by other changes in the upcoming release)

Yeah we still need to do the

• SingleDerivedPath -> DerivingPath
• DerivedPath -> WeirdDerivedPath

Rename.

It does have one somewhat legit store layer use-case in making a "build all outputs" goal in the Worker can be thought of as a kind of pipelined RPC as in

I would just tell you what all the outputs are, but I don't have the derivation yet, and you're about to get it / make it, so why don't you figure it out for me.

The alternative would be the CLI (or whatever else) doing two Worker invocations, first to get the derivation, and then to get the derivation's outputs.

Do I understand correctly that this JSON format is not in use by the public yet? (If it is, a release note should be added, as well as relevant version field bumps, if not already bumped by other changes in the upcoming release)

I think so, but I should double check.

a kind of pipelined RPC

Do we have a real use case for that and is it more than one roundtrip?

The use-case is just the CLI wildcards (and other things grandfathered in like :b in the REPL). It would be just a single round trip, yes, so not so bad.

I think so, but I should double check.

Yes, this is unused except for by tests. Ah I checked DerivedPath, but I forgot about ExtendedOutputSpec. checking now.

Oh hmm, this does affect the nix profile manifest.